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(54) Method and apparatus for processing and printing documents 



(57) Tlie present invention relates to a metliod and 
system for efficient image handling. The invention in- 
cludes an image server (10) with w/hich image files are 
registered. The image processing requests are sent to 
the image sen/er to produce image data representing 
the processed image file, in one embodiment of the in- 
vention, a document processing application obtains (60) 
an image file for printing. The application registers (62) 
the image with the image sen/er. The image server re- 
turns an identifier (68) identifying the image file which is 
used for subsequent image processing requests. The 
application initiates a print job, sending (90) the image 
identifier and selected print parameters to a printer driv- 
er (300). In response, the printer driver negotiates image 
processing requests (70) with the image server to mod- 
ify the image file in accordance with the selected print 
parameters. Finally, the processed image data is re- 
trieved (72) from the image server and sent (92) to the 
printer. The image server and printer driver may be sep- 
arate and independently executing processes. In an al- 
ternate embodiment, the application, image server and 
printer driver are loaded on two or more networked com- 
puters. 
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Description 
TECHNICAL FIELD 

5 The present invention relates generally to processing documents and more specifically to a method and system 

for preparing documents for printing. 

BACKGROUND ART 

10 Image processing has become a commonplace activity due to the ease and availability ol the hardware and soft- 

ware used to capture images. The popularity and accessibility of the Internet, and more importantly the creation of the 
World Wide Web, have greatly increased the use of images. However, the processing of captured images and other 
graphical elements is generally more complex as compared to the processing of textual data. For example, color images 
may need to be color matched between a video display and a printer, edge enhanced to extract certain features, and 
so on. Such manipulations tend to be CPU intensive, and because of the large amounts of data typically associated 
with image files, especially color images, such manipulations also tend to be I/O intensive. One area that is affected 
by the increased use of images, for example. Is the preparation and printing of documents containing such images. 

Because of the availability of sophisticated word processing and other desktop publishing programs, documents 
generally no longer consist solely of text data, but rather include a variety of Images. Preparing such documents for 

20 prinlingon a compulermay require several image processing operations including scaling, clipping, sharpening, various 
transformations and the like. These operations are performed either by the application or by printer driver software 
normally included with the printer. As a consequence of incorporating images into a document, the computer system 
will experience a high degree of loading due to the processing of the large amounts of data, typical of graphical image 
elements. Several approaches to document preparation and printing exist. 

25 Some applications prepare a device independent bitmap of an image of the document to be printed. The bitmap 

is then sent to a printer via its corresponding printer driver software. In most cases, the application has no knowledge 
of the printer's requirements. For example, a user may decide to print a medium quality image using a certain kind of 
paper This requires that an image of the document be created with a certain resolution and bit depth. The application 
cannot determine the resolution and/or bit depth needed to render output In accordance with the print parameters 
selected by the user Such knowledge is contained in the printer driver The application, having to accommodate any 
kind of printer, therefore takes a conservative approach and sends a copy of a high resolution bitmap of the Image to 
the printer driver. The primer driver then performs additional processing {e.g. decimation) on the received copy of the 
high resolution image to generate output for the printer at the appropriate resolution. 

This simple approach is a very inefficient way of printing. The application always generates a high resolution copy 

35 of the document regardless of the printer and the selected print parameters. This translates to the unnecessary process- 
ing of large amounts of data, requiring excessive disk activity as intermediate files are created, written out to the disk, 
read in from the disk, processed, written back out to the disk and so on. Such activity adversely impacts the user since 
access to the CPU is blocked until the print job has completed. 

In another approach, the document processing application queries the printer driver to determine what image 

4:- processing capabilities exist in the printer driver. The application then decides how to divide up the image processing 
tasks between the application and the printer driver. The application produces an appropriate image of the document 
and sends a copy of the image to the printer driver. The printer driver performs any required additional processing on 
the copy of the received image and outputs a final printer image of the document to the printer. Knowing the image 
processing capabilities of the printer driver improves efficiency, since printer-specific processing such as output reso- 

-fs lution generation is performed by the printer driver. The application no longer needs to generate a high resolution 
bitmap in an attempt to accommodate all printers. Rather, the application performs only device-independent operations 
such as clipping, red-eye correction, sharpening, etc., operations not typically supported by the printer driver This 
results in a smaller image file that is then passed from the application to the driver From the standpoint of the user, 
however, the CPU still is tied up until the application has processed the image and passed a copy of the image to the 

so printer driver, at which point the printer driver performs additional primer-specific processing on the received copy of 
the image and outputs the generated printer image to the printer. 

To alleviate the waiting,' most comi^uiers use a technique known as spoofing to return the CPU to the user as 
quickly as possible Irom a print job. The printer image, i.e. the bitmap image that is actually sent to the printer, is copied 
out :o the disk and sent to the printer as a background process. This allows the printer driver to return control of the 

ss computor back to the user wtthoi;: having to wait for the actual output to be produced. However, transmitting ihd'finai 
primer imago to the primer quite often represents only a small fraction ot the toial effort of the print job. most of the 
ef^o.-l and time being expe.nded Ixjth by the application and the printer driver to produce the printer image of the doc- 
ument in the first place. 
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One operating system has taken the spooling technique one step further. Under the Microsoft® Windows '95 op- 
erating systenn, a method known as enhanced metafile format (EMF) spooling was implemented. With EMF spooling, 
the operating system (OS) spools up all of the calls that the appiicatbn makes to the printer driver to a spool file, much 
in the same way that a printer image is presently spooled. The OS then plays back the spooled file, sending the spooled 

s information to the printer driver, thus completing the print job entirely in the background. Control of the computer is 
relumed to the user sooner under EMF spooling, since the user no longer must wait for the printer driver to perform 
its image processing operations. 

Yet, even with EMF spooling, there still are factors which impact system performance during printing. Most notably 
is the fact that large amounts of data are being passed through the system. For example, consider a 24-bit color 

10 digitized image ot an 8' x 10" photograph. Roughly 20 megabytes of data are needed to represent such an image at 
300 dpi and 80 megabytes of data at 600 dpi. With EMF spooling, the OS spools up the calls made to the printer driver 
from the appiicatbn, along with a copy of the 20 or 80 megabytes of data that represent the image. The spooled file 
is written to disk. During playback, the spooled file (which includes the 20 megabytes of image data) is read back from 
the disk and handed to the printer driver. As the printer driver prepares the printer image, temporary files are created, 

'5 stored on the disk, read from the disk, written back out to the disk and so on. All of this disk activity takes its toll in the 
response time and overall performance of the OS. What the userperceives is a very slow and otherwise non-responsive 
system. 

While the foregoing discussion has focused on the bottlenecks experienced during the processing of a print job, 
similar bottlenecks exist in the processing of images in general. What is needed is a n-.ethod and system which mini- 
20 mizes the amount of data being passed by the OS during the handling and processing of images. In particular, a method 
and system is needed to more efficiently process a print job. It is also desirous to minimize the disk activity experienced 
by the OS dunng the processing of an image, such as during a print job. 

SUMMARY OF THE INVENTION 

2S 

In accordance with the present invention, processing an image to produce a desired appearance of the Image 
begins by registering the image with an Image server, The image server returns a handle, identifying the image within 
the image sen/er Image processing requests then are sent to the image server in accordance with the desired ap- 
pearance of the image. The processed image is then retrieved from the image server. 

30 in one embodiment, a method and system for printing a document includes registering the document with an image 

server and subsequently receiving from the image server an identifier identifying the document. The document lo be 
printed is registered with the image sender by passing to the image server a file descriptor which identifies the location 
of the document. The file descriptor typically is the filename of the document located on disk, but may be a pointer to 
a location in shared memory where the document is stored. Continuing, the identifier is passed to a printer driver, along 

35 with print parameters describing the desired appearance of the printed document. Using the identifier to reference the 
document, the printer driver sends image processing requests to the image server, directing the latter to form a printer 
image by processing an image of the document in accordance with the print parameters. Finally, the printer driver 
retrieves the printer image from the image server, which consists only of the image data of the processed document 
needed for downbading to a printer. 

40 The amount of data being passed through the system during printing is kept to a minimum. For example, rather 
than copying large volumes of data representing the document from the address space of one process into the address 
space of another process, an identifier is used instead. The identifier serves to identify the document, and because it 
is an identifier of the document and not the document itself the amount of data passed is significantly less. 

Another feature of the present invention is that only those portions of the image that are needed to form the final 

45 printer image are accessed by the image server. In this way, the amount of handling of the images contained in a 
document is minimized. The result is lower disk activity (or saving and loading data to and from the disk during the 
formation of the printer image. In addition, the load on the CPU is less. This has the overall effect of providing a quicker 
turnaround lime for the user issuing a print command and improving system periormance. 

In a preferred embodiment of the present invention, the user application which initiates the print jobs executes 

so separately from and independently of both the image server and the printer driver. Similarly, the image server and the 
printer driver may be separate, concurrent and independently executing processes. If the OS supports multi-tasking 
operation. When the image server receives a request from an application (e.g. a word processing application) to register 
a document, the image server will lock the document to prevent other processes from accessing the document. This 
ensures the integrity of the document during the time the image server produces the desired printer image. Neverthe- 

ss less, upon receiving a subsequent unlock request, the image server can make a temporary copy of the document and 
unlock the original. Since the document is referenced by way of the identifier originally provided by the image sen/er, 
processes outside of the image server are unaffected by the copying. 

In a variation of the preferred embodiment, two or more applications are loaded, each selecting a document to be 
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printed ^nd cnch issuing a print job in accordance with the present invention. Similarty. two or nrore printer drivers may 
hn in-tcirri nnr) oxnr.uied fls separate program units. In this way, more than one kind of printer can be supported. Each 
such prnicr duvci is wtitlen or otherwise configured with the ability to communicate with its corresponding printer. 

In yd rtnoihci variation of the preferred embodiment, the image server and printer driver{s) may reside on two or 
ruDic nciwotkcd computers. The app!icatlon(s) can be co-locaied with the image server or printer driyer(s), or located 
on scprtfHic compuiors This provides maximum flexibility in configuring a site having multiple workstations configured 
Hfound a tiic sofvor and one or more printers, while at the same time realizing the performance benefits made possible 
by ;hc pfcscni mvcnlton. 

BRIEF DESCRIPTION OF THE DRAWINGS ' ; . 

Figure 1 IS h system diagram of an embodiment of the present invention. 

Ffgutc 2 rilusi rates a typical sequence of events when processing documents in accordance with the present 
invcniton 

Figutc 3 sfiows iho tnterfaces between the software components of the system of the present invention. 
P.igufc 4 IS n system diagram of the present invention arranged in a networked configuration. 

BEST r^ODE -C^ CARRYING OUT THE INVENTION 

The bci>i fruxJo coniomplaled for practicing the present invention is depicted in the system block diagram shown 
in Fig 1 iti .-i llkhjuIlm system 40, oneormore userapplications 100, 200 generate and manipulate documents through 
interactionb w!h users Such applications include word processing programs, drawing programs, spreadsheet pro- 
grams, documorii rtsscmbty programs, photographic imaging programs and the like. The term 'users' is herein defined 
as eithcf n rium<in user interacting with the application, or an automated agent which interacts with the application; e. 
g. software wticn cfTiulnicG a (ax machine autonnatically receiving incoming faxes, image scanning software, automated 
data retriovHi toHwHro otc. The applications 100, 200 have access to a data store 30 for storing and retrieving data 
as neeocd The dntn store 30 further includes areas within the address space of the application's random access 
memory (RAMi Hnd may re-ler to different areas within shared memory. 

An inv-pr prnrrssing server 10 provides Image processing capability for manipulating image-containing docu- 
ments The nr-pltcHtons lOO, 200 communicaie with the image ser/er 10 by way of an image sen/er interface, which 
IS described r qrcHior detail beiow. Like the applications, the image server 10 has access to the data store 30. 

Some ol tnc npplicaitons 100 are shown in communication with printer drivers 300, to which printing devices 22, 
24 are conncc:od E^ich of the printer drivers 300 is written specifically tor a particular type and/or kind of printer device. 
For example the printer device 22 may be a plotter, while the printer device 24 is a laser printer. Alternatively, both 
printer dovccs 22 24 may be Inkjet printers, but from different manufacturers and each requiring a driver which can 
communicate with the device. 

An aspect of the invention is and the printer drivers 300 may be loaded as independently executing program units; 
i.e. each is h separate process. Communications among the processes are provided through well known and fully 
understood interprocess communication (IPC) techniques, such as RFC OLE and COM. Most operating systems (OS) 
support at least some form of multitasking and also provide for IPC among processes. Typical OS's include: the many 
incarnations ol ihc UNIX OS; the Macintosh OS; Windows 3.x; Windows '95 and Microsoft NT This list, of course, is 
merely excmplnry and not intended to be limiting. The present invention can be effectively inplemented on other 
muttfiasking systems wtiich support IPC. 

The llovw:nHrt shown in Fig. 2 illustrates the steps typically performed when printing images and documents in 
accordance w:tn ino present invention. The sequence shown in Fig. 2 corresponds tothe appllcatbns lOO and printer 
drivers 300 shown in Fig 1 . First, a document is obtained by an application 100, either by reading in a file from the 
data store 30 ano/or irom input provided by a user of the application, step 60. The document is identified by the name 
of the lile on disk, or by an address pointer in memory where the document is stored. In addition to obtaining the 
document. Hie application lOG obtains frorn the user piinl parameters describing the desired appearance of the printed 
document. 

Continuing, the application 100 registers the oocument with the image server 10 by sending its file name, or its 
address pointer to me image server, step 62. Recall that the applications 100. 200 and the image sender 10 may be 
incicpcndcniiy executing processes. Each process therefore may have its own logical address space, which generally 
iS no! directly accossifcle by other processes. Thus, if an application registers a document by way ol an address pointer^ 
\he d:>cumont must reside in a shared memory' region which can be accessed by iwo or more processes. Similarty, an 
-^idc r'iss posntor mny bo used wrien trie data exists in one address space, as in the case writh dynamically linked lioraries. 

lipc*n recniving the document identifier, the image server 10 creates a handle which identifies the document inde- 
pendently of the Identifier provided by the appiication lOC, step 64. Although the term "handle* typically implies certain 
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data structures, the references to "handle" in this application are not intended to be limited to such data structures. 
Rather, any Implementation of a "handle" consistent with the description given in this application Is contemplated. 
Continuing, the Image sen/er then locks the document to prevent access to It by other applications, step 66. The 
document handle and document locking mechanisms ensure the Integrity and consistency of the document while it Is 
5 being processed by the Image server. For example, if a second application attempts to modify the document, it must 
iirsl send an unlock request to the image sen/er. The Image server may respond by making a local copy of the document 
and unlocking the original. The image server subsequently references the local copy, and relinquishes the original 
document so thai the second application may access it. 

Continuing, the application 100 receives the handle created by the Image server and sends It and the specified 
'0 pnni parameters to the printer driver 300, steps 68 and 90. The printer driver 300 then sends one or more image 
processing requests to the image server 10 to process the Image identified by the handle In accordance with the print 
pHfHmeters, step 70. Next, the printer driver retrieves the processed Image data from the image server, step 72, and 
sends the retrieved image data to the corresponding printer 22, 24, step 92. Finally, the document is unlocked, step 74. 

It the image server creates a local copy of the document as described above. Image processing requests will be 
1^ drcciod to the local copy. The fact of the copying is completely transparent to the printer driver, since it uses the 
document handle to refer to the document. Upon completion ot the print job, the image server will delete the local copy 

Cienerally, the image server 10 provides the bulk of the image processing operations in the present invention. 
However, it may be desirable to limit the processing capability of the Image server to those generic operations which 
Hrc independent ot any kind or type of printer. Any printer specific image requirements can be perfonried by the primer 
unvuf upon retrieving the image dala In step 72 to form a final printer image which is then sent to the printer. 

Fiyuie 2 includes additional steps 80 through 84. which address the issue of backward compatibility. Prior to reg- 
rsicf ng !hc document with the image server 10. the application 1 00 first queries the printer driver to determine whether 
ti 1-15 rto interlace to the image server, step 60. If the response is negative, the application proceeds along the lines 
oi inc prior art printing methods Typically, this means the application produces a device independent bitnnap (DIB) 
.-f rrrLiq:; ol the document to bo printed and sends the DIB image to the printer driver for subsequent printing, steps 82 
nnd r-i HowGver, If the printer driver supports an image server interface, then the application continues along steps 
cr thfOLgh 92 as described above, 

!'i nnoiher embodiment, also depicted in Fig. 2, the method of the present inventbn includes only those steps 
M-i -finiiod by the refernncf^ numornls 60 through 72. This sequence corresponds to the applications 200 shown in Fig. 
-10 1 This Hiiomriie embodimcni is a gnnorHh/alion of the present invention, of which the above-described printing process 
ts M soocirti CHse. In the Qoncrnli/od method, the application 200 itself communicates with the Image server to effectuate 
ac',,«iea trrvige processing opornions on the document, step 70, In addition, the resulting processed image data is not 
ncccii,^ftiy printed, but rHthcr mny simply be stored onto the data store 30. or displayed on a video terminal. 

The discussion will now turn to ihc components of the present Invention. Numerous software modules comprise 
J? m:>st ot :hc major components ol the system As such, many existing programming languages can be used to practice 
Ihc invoition: most notably the C nnd C* ♦ languages. The functions of the software modules are defined in temns of 
mc riopi cHiions programmer nicriHCc i API > for each module, the specific implementation details simply being a matter 
ot producing the code to portotm iho opcfHiions required to implement the API. In some cases, however, it may be 
noccD&--.ry to explain the opcvition in icfr-is d( an actual OS. In order to provide the needed context in those cases, 
-to the V/incJov/s '95 operHiinc systoni cnvnonmont will be used. 

Rcicirng to Fig 3 Ihc appiicrfton lOO typically includes the following components: application specific code 101; 
pnnici utiiriios 302 for comTiumcTiimg with the punter driver 300; I/O utilities 32 for reading and writing a memory store 
30 rtnd tmrtge server utilities 12 lor communtcatrng with the image server 10. The application specific code 101, of 
course vHrics depending upcn no appic^itton As mentioned above, various types of applications are contemplated, 
■ii' incluamg word processing dfHwnq proqinms spreadsheets, desktop publishing programs and so on. 

Tho pr tnier drivers 300 tnciuoe C( ivof spoctlic code 301 (or communicating with printing devices, and further Include 
the rmngc server utilities lor communicating with the image sen/er. In addition to providing a communication interface 
to lite ptinimg device, the dnvci sp-jci ic cuac 301 may pertorni certain image processing operations specific to the 
pimtei In this way, the imago btnvui 10 nuodb lo provide only those image processing operations that are device 
so indopendenl. 

The imago server 10 includes ittc I/O utiltties 32 and image server specific code 11 which Implements Image 
processing operations such as resolution icnimg. image enlargement/reduction, clipping, red-eye correction, rotations, 
feature extraction, edge enhancement .ird co on. Such operations aro known and understood by those of ordinary 
skill in tho cornputGi imaging and compgior graphics arts. The image server can be designed to support one or more 
55 o( the many types of imngo tormpiis that oxist in the industry. Including but not limited to JPEG, MPEG, GIF, TIFF, etc. 
It IS noted that the specific formats supported by tho image server are not critical to the practice of the present invention. 
Rfiiher, the choice ol forrnal(s) will ciopr^nci on weighing certain factors such as desired capability of the image server, 
complexity of the code, complexity ol iho image formats, processing capacity, storage requirements, operating envl- 
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ronment, system cost. etc. 

The I/O utilities 32 perfom standard operations, including: open a file, close a file, read from a file and write to a 
file. Such operations are fully understood by those skilled In the software arts and therefore require no further elabo- 
raticn. 

• 5 The printer utilities 302 enable the application 100 to communicate with the printer driver 300 to initiate a print job. 

Included in the printer utilities is a function which enables the application 100 to detemnine whether the printer driver 
300 supports an image server interface, see step 80 in Fig. 2. Under Windows '95, for example, this may be accom- 
plished by nnaking a system call to ExtEscapeQ for the IS_SUPPOiTr code (image server support). A printer driver 
SCO which supports the image server 10 will recognize the IS_SUPPORT code and respond affirmatively. Consequently, 

10 the- return value Horn the call to E)rtEscape(QUERYESCSUPPORT, IS_SUPPORT) will be positive. Otherwise, the 
retum value will be.O (zero), indicating that the image server is not supported. 

If the image server Is not supported, the application will continue processing in the manner presently done in the 
prior art. .Namely, the application will generate a DIB image and send the image to the printer driver 300, which under 
Windows '95 is done by making a system call to StretchDIBits() and passing a pointer to the DIB image. On the other 

IS hand, if the printer driver supports the image server, the application will obtain a handle to the inrage (see below, see 
also step 63 of Fig. 2) and make the system call to Stretch DIBitsQ. passing the handle instead of the DIB image. 

The image server utilities 12 define the interface to the image server. Thus, image processing operatbns are 
effectuated by making the appropriate calls to the utilities. The applicat bn programmer's interfaces (API's) for the image 
server utilities will be discussed below. These API's define the functionality of the image server and thus obviate the 

^0 need to provide examples of the source code that implements the image server, which will depend on the OS and the 
programming language used. It is understood that a person of ordinary skill in the programming arts can produce the 
code which implements the functions defined by the API. 

As mentioned above, the image server 10 is capable of supporting a variety of Image fornriats. Since the image 
server is accessed through the image server utilities 12, the image server can be easily extended to support additional 

25 image formats as new formats are defined. The presence of the image server utilities 12 makes this extension com- 
pletely transparent to applications/drivers which use the image server, thus maintaining backward compatibility when 
the image server is upgraded to support new image formats. " " , 

Figure 3 shows the API definitions for the image server utilities 1 2. The figure shows the utilities are divided between 
the application 100 and the printer driver 300. This is not necessarily the case, however Depending on the particular 

30 use. all of the listed utilities may reside within one application, or may be divided among a number of applications. In 
abhabetical order, the API's are: 

Cbselmage 

35 Function: 

Informs the image server that processing of the image file is complete. The image server will unlock the 
image file to allow access to the file by others. 
Parameters: 

ihimageHandle • Identifies the Image file. 
-0 Returns: 

TRUE - Function was successful. 

ISE_NOTREGISTERED - ihimageHandle does not map to a currently registered image file. 
Contigurelmage 

4S -. . . . . . ... . .. 

Function: 

Informs the Image server of the image processing operations (formatting options) to be performed on the 
image. 

Parameters: ' . 

50 ihimageHandle - Identifies the image file to be processed. 

ipimageProcOptions - A data structure which contains the requested image processing options. 
Returns: 

TRUE - Function was successful.- 

ISE_FORf/AT_NOTSUPPCRTED - Specified format is not supported by the imiage server. 
55 ISE_NGTREGISTERED - ihimageHandle does not map to a currently registered image file. 
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Openlmage 
Function: 

Informs the image sen/er that image processing operations are to be performed on the specified image (via 
s calls to ConfigurelmageO). 

Parameters: 

ihlmageHandle - Identifies the image file. 
Returns: 

TRUE - Function was successful. Image sen/er is ready to accept image processing requests for ihlmage- 
^o Handle. 

ISE_NOTREGISTERED - ihlmageHandle does not map to a currently registered image file. 



QueryFomnatSupport 
15 Function: 

Queries the image server as to whether the image server supports the specified image format. Information 
may be provided indicating additional processing capability supported by the image server tor the specified image 
formal. 
Parameters: 

20 dwImageFormat - The specified image format of interest. For example, TIFF, JPEG, MPEG, GIF 

IpFormatData - Pointer to a data structure Indicating additional processing capability, e.g. compositing, pro- 
vided by the image server. 
Returns: 

ISE_FOnMAT_SUPPORTED - Specified format is supported by the image server If IpFormatData is not the 
2S NULL pointer, then additional formatting features may be specified therein by the image server 

ISE_FORMAT_NOTSUPPORTED - Specified format is not supported by the image server. 

Querylmage 



30 Function: 

Provides information about the specified image file. 
Parameters: 

ihlmageHandle - Identifies the image file for which information is desired. 
Iplmagelnfo - Pointer to image information data structure. Filled in by the image sender. 
35 Returns: 

TRUE - Function was successful. 

ISE„NOTREGISTERED - ihlmageHandle does not map to a currently registered image file. 



Registerlmage 

40 

Function: 

Locks and/or copies the specified image file and returns a private handle to the locked/copied image file. 
The handle is used for subsequent access to the file. 
Parameters: 

45 IpszlmageFileName - Points to a fully qualified path/file name of the image file. Alternatively, the image file 

may be passed by a pointer to a buffer, in which case, IpszlmageFileName is the NULL pointer. 

IpJobData - Points to a structure containing pertinent job data, such as the name of the print device. 
dwImageFormat - Specifies the image format of the specified image file. 

IplrnageHandle - Points toa buffer into which the image handle (generated by the image server) will be cc^ied. 
50 IplmageData - Points to a buffer containing the image file. Aflematively, the image file may be referenced by 

a fully qualified path/file name, in which case IplmageData is the NULL pointer. 

IplmageDataHeader - Points to a data structure which defines the format of the data pointed to by I plmage- 

Data. 

. This is the NULL pointer if IplmageData is also the NULL pointer. 
' ■- ss . dwOplions;- Specifitss how the. image is file is registered with the image server. Valid values include: 

- IS_TEMPFILE - Tlie file pointed to by 

IpszlmageFileName is a temporary file that is to be deleted by the image server when a call to Close- 
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Image is made. 

I S_COP YNOW - The file pointed to by 

IpsztmageFileName is a not temporary file, but the image server should. make a copy of the image file 
rather than locking the file. 

Returns: 

TRUE - Function was successful. IplmageHandle points to a valid handle (created by the image server) for 
(he image. 

ISE_OUTOFSPACE - Could not make requested copy of image file. IplmageHandle contents are undefined. 
ISE_FORMN0TSUPP • Format specified in dwImageFormat not supported by this version of the image 
server. IplmageHandle contents are undefined. 

RotnevelmageBand 

Function: 

Requests the image data of the processed image, generated by the image server as a result ot preceding. 
cail(sl to Configuretmage(). 
Parameters: 

thImageHandle - Identifies the image file. 

XSrc - X-coofdinaie ol the desired portion of the image data generated by the image server, in pixels. 
YSrc - Y-coordinate of the desired portion of the image data generated by the image server, in pixels. 
cxSrc - Width o( the desired portion of the image data generated by the Image server, in pixels. 
cySrc - Height of the desired portion of the image data generated by the image server, in pixels. 
IpBandBulfer - Pointer to a buft er in which the image server is to place the requested portion of the generated 
-5 imrjgo data. 

IpBandHoader - Pointer to a data structure which specifies the format of the image data to be stored in 
IsBrindBuffer, 
Returns: 

"TRUE - Function wh£ succossfiit 

iSE_FROCFRROR • Pfoccsr^ng error encountered by the image server. 

ISE_NOTCONFIGURED • No processing operations have been pertormed. No calls have been made to the 
ijnciton ConligurolnvigeO 

ISE NOTREGISTERED • ihlmageHandle does not map to a currently registered image file. 

Uniocktmage 

Function. 

Removes [ho liic lock on ps/irr^HgoFileName i1 the file is currently locked by the image server. In doing so, 
t^c imnge server will rrvjkc ^ tompoirtry copy of the image file. 
~o PHfHmelers: 

IpszImagcFilcN^imo - File nrtmc ol the image file to be unlocked. 
Returns. 

TRUE - Function whs successtui ipszlmageFileName is unlocked. 

lSE_OUTOFSPACh - Could no; nvike a copy ot the image file in order to unlock IpszlmageFileName. The 
•Ji- imngc lile remains locked by tno imrtgo sender. • 

I SE_NOTUNLOCK • Could not unlock IpszlmageFileName. This typically indicates that the file was not locked 
by me image server. 

Tlie toliowing fragment ol pbcucu-codo illusliates how the above calls might appear in a typical dccument-|-iandilng 
application 
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r is JPEG supported? */ 
dwImageFormat <- JPEG image format 
QueryFormatSupportl dwImageFormat, IpForrr.atData ) 
if ( return value = = ISE_FORMAT_N0TSUPPORTED ) 
exit 



I" register the image file */ 
IpsztmageRleName <- document file name 
IpJobData <•- user specified printer, printer options 
dwImageFormat <- JPEG image format 
IplmageOata <- NULL 
- IplmageDataHeader <- NULL 
25 dwOptions <-- IS_C0PYN0W /* do not lock the file */ 

Registerlmage{ IpszlmageFileName, IpJobdata, dwImageFormat, 
IptmageMandle, IplmageData, IplmageDataHeader, dwOptions ) 
2Q Iff return value ! = TRUE ) 

exit 



send handle (IpimageHandle) to the printer driver, 
along with print parameters 



45 

The following pseudo-code fragments illustrate how the image server utilities might appear in the printer driver 
software: 



so 



SB 
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/* teii image server: about to start image processing •/ 
ihlmageHandle <- image handle received from user application) 
Openlmaget ihlmageHandle ) 
if { return value = = IS£_NOTREGlSTEHED I 

inform user apaiication; invalid handle 

exit 



/* perform image processing */ 

for all prim parameters received from user application, do 
iplmageProcOptions <- print parameters 
Configurelmagei inlmageHandle, iplmageProcOptions ) 
if( return value = = IS£_F0RMA7_N0TSUPP0RTED I 
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inform user application: invalid print parameter(s) 
exit 

^ continue 

/• obtain image data of the processed image and send to printer '/ 
10 XSfc <-■ X-coofdinate of initial segment of the processed image 

YSrc <" Y-coordinate of initiat segmen: of the processed image 
cxSrc < width of image portion 
cySfc < - height of image portion 

IpBandHeader <-- retrieve the processed image in GIF format 
for all segments of the processed image data, do 
RetrievBimageBand{ thlmageHandie, Xsrc, Ysrc, 
cxSrc, cySrc, IpBandBuffer, IpBandHeader ) 
send segmeni pointed to by IpBandBuffer to the printer 
increment to the next segment of the processed image 
Xsr= <~ X-coordinate of next segment 
Ysrc <" Y-coordinate of next segment 
continue 
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22 Cioseimage( ihlmageHandie 



40 

The discussion will nowtum loan embodiment of the present invention depicted in Fig. 4. Whereas the components 
of the invention are shown in Fig. 1 as residing on one computer, the same components shown in Fig. 4 are distributed 
over two or more networked computers. The computers 42 through 48 are interconnected by a network 50. The network 
50 may be an Ethernet backbone in a LAN (local area network) or may include the telephone network in a WAN (wide 
area network), f^ore generally, the computers 42 through 48 may be interconnected by some combination of LAN and 
WAN. The present invention can be practiced with any network configuration, and is not limited to any one architecture. 

Each computer communicates over the network via its network interface 52. The interface 52 includes the hardware 
and server software needed to allow the particular computer to access another computer over the network. Recall that 

50 the applications 100, image server 10 and printer drivers 300 are separate processes, and that communication among 
these processes is accomplished by appropriate IPC calls. In a networked configuration, the IPC calls must be replaced 
with equivalent remote procedure calls (RPC) so that these processes can operate over the network. While the imple- 
mentation of RPC generally depends upon the capabilities of the particular OS, it nevertheless is within the scope of 
a person of ordinary skill in the programming ans. 

55 Figure 4 shows a computer which junctions as a disk server 44. Resident on the disk server Is an image server 

10 cf the present invention. Printer drivers 300' are also loaded on the disk sealer 44 to drive printers 22, 24. Another 
compLiler 48 serves primarily as a printer ser^/er for printers 26, 28. User applications 100 residing on computer 42 
can access liles on the disk 30, via server softv/are running on the disk server 44. User applications 200 running on 
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computer 46 operate in a similar manner. 

Although the components of the present invention are distributed, the operation of the invention remains the same. 
Thus, for example, a Registerlmage() call can be initiated from the application 100 on computer 42, sent across the 
network to computer 44 and processed by the image server 10. The image server 10 creates a handle and returns the 

5 handle to the application 100. The application then communicates over the network to initiate a print job virith printer 
driver 300' on computer 44. From there, the printer driver 300' and image server 1 0, operating vnthin the same computer 
44. interact in the nnanner described above to produce the final printer image. Alternatively, the application 100 may 
initiate a print job with printer driver 300" on computer 48. Like the printer driver 300' on computer 44, the printer driver 
300" on computer 48 negotiates image processing requests with the image server 10. However, unlike the printer driver 

10 300' on computer 44, the printer driver 300* must negotiate the image server calls over the network. 



Claims 

'5 1. A method of processing images, comprising the steps of: 

(a) obtaining (60) a digitized image; 

(b) specifying transformation parameters indicating a desired appearance of said digitized image; 

(c) registering (62) said digitized image with an image server (10); 

^0 (d) in response to said step of registering, receiving (68) an image identifier handle from said image server; 

(e) sending (70) image processing requests to said image server to produce image data of said digitized image 
in accordance with said transformation parameters, including sending said image identifier to said image server 
to identify said digitized innage, whereby said desired appearance of said digitized image is produced; and 

(f ) retrieving (72) said image data from said image server 

25 

2. The method of claim 1 further including loading a user application and said image server (1 0) as concurrently and 
independently executing programs (100) on a computer (40), said user application performing said substeps (a) 
through (f). 

3. The method of claim 1 or 2 further inducing loading first and second user applications (100) on a computer (40), 
said first user application performing said subsleos (a) through (e) for a first digitized image, said second user 
application performing said substeps (a) through (e) for a second digitized image. 

4. The method of claim 1 . 2 or 3 further including loading a user application (100) on a first computer (40) and loading 
■35 said image server (10) on a second computer, said user application performing said substeps (a) through (f). 

5. The method of claim 1 , 2, 3 or 4 further including: 

loading a user application (100), said image server (10) and a printer driver (22), each as a concurrently and 
■'V independently executing program unit, said printer driver being configured to communicate with a first type of 

printer; 

said user application performing substeps (a) through (d); 

transmitting (90) said image handle and said transformation parameters from said user application to said 
printer driver subsequent to performing said substep (d); 
45 said printer driver performing said substeps (e) and (f); and 

transmitting (92) said image data from said printer driver to said first type of printer . ■ . 

6. The method of claim 5 further including a step of loading a second printer (24) driver on said computer as a 
concurrently and independently executing program, said second printer driver being configured to communicate 

50 with a second type of printer. 

7. The method of claim 5 further including loading a user application (100) on a first computer (42) and loading said 
irph-ige server and said printer driver on a second computer (44). 

-''•5 8. A system for printing documents from a document processing application, said sysiem including: 

a first memory store (30) cnntaintng a pluralir/ of documents, said documents having document locators which 
specify the location ol said documents in said first menrtory store; 
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an image processing server (10); and 
a printer driver (300); 

said image processing server being an independently executing program unit; 

said image processing server having circuitry (1 1 ) (or generating a document identifier upon receipt of a 
s document locator, said document identifier identifying the document specified by said document locator; 

code (301 } for initiating a print job, including code for communicating one of said document locators to said 

image processing server, code for obtaining a corresponding document identifier from said image processing 

server and code for communicating job parameters to said printer driver, said job parameters including print 

parameters and said corresponding document Identifier; 
10 said printer driver having code for manipulating image data of the document identified by said corresponding 

document identifier, including code for sending image processing requests to said image processing server 

in accordance witin said print parameters; 

said printer driver having code for obtaining said manipulated image data from.said image processing server, 
and further having code for transmitting said manipulated image data to a printer of a first kind. 

IS 

9. The system of claim 8 wherein said document processing application, said image processing sen/er (10) and said 
printer driver (300) are resident in a single computer (40). 
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